IBIS Macromodel Task Group Meeting date: 22 October 2024 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Altair: Junesang Lee Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Aurora System: Dian Yang Raj Raghuram Cadence Design Systems: * Ambrish Varma * Jared James Dassault Systemes: Longfei Bai Google: Hanfeng Wang GaWon Kim Intel: * Michael Mirmak [Kinger Cai] Chi-te Chen Liwei Zhao Alaeddin Aydiner Sai Zhou Keysight Technologies: * Fangyi Rao Majid Ahadi Dolatsara Stephen Slater Ming Yan Rui Yang Marvell: Steve Parker Mathworks (SiSoft): Walter Katz Graham Kus Micron Technology: Justin Butterfield Missouri S&T: Chulsoon Hwang * Yifan Ding Zhiping Yang Rivos: Yansheng Wang SAE ITC: Michael McNair Samsung: Jun-Bae Kim Siemens EDA (Mentor): * Arpad Muranyi * Randy Wolff Signal Edge Solutions * Benjamin Dannan Teraspeed Labs: [Bob Ross] Zuken USA: Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: Randy: Update Yifan on the discussion in the meeting and ask her to redo the 50 Ohms to Vcc experiment into Vddq instead. - Done. Yifan: Perform additional investigations into the applicability of BIRD220.1 for devices with independent pre-driver stages. - Done. Michael: Prepare a new draft BIRD updating the language surrounding Ts4file and Ramp and related cross checking. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the October 15th meeting. Michael moved to approve the minutes. Ambrish seconded the motion. There were no objections. -------------- New Discussion: Ts4file and [Ramp]: Michael reviewed his proposed changes, which are intended to resolve any ambiguities related to [Ramp], Ts4file, and V-t waveforms. He had sent them to ATM the day before the meeting. The changes included: Tx_R and Rx_R: New text was added to explicitly state that these are optional and used, at the discretion of the model maker, to represent part of the actual transmitter or receiver impedance respectively. (pgs. 315, 316) Ts4file: New text was added to explicitly state that Ts4file uses 4-port circuit data as an alternative to the model information found in C_comp, I-V tables, and V-t waveforms. It also explicitly stated that [Ramp] and C_comp were still required when Ts4file is present, and that any of the other (optional) I-V and V-t information should be consistent with the "output behavior of the buffer... under identical loading" when Ts4file is present. (pg. 315) [Ramp]: A new Other Notes section for [Ramp] was introduced. It is intended to resolve any confusion, and it states that [Ramp] is intended to be an expression of the loaded output buffer behavior, and it is never used to represent the stimulus provided to the buffer. It states that [Ramp] behavior should ideally be consistent with all other data (e.g., Ts4file, I-V, V-t, [External Model]), but it notes that it may not be possible to cross-check with all types of data, particularly [External Model]. (pg. 104) [External Model]: This change removed the [Ramp] keyword from the list of "usual" data that the [External Model] keyword can be used to replace. This was done because [Ramp] is always required and specific rules for [External Model] are already given on page 136. (pg. 130) [External Model]: In the Usage Rules section, an unnecessary and misleading usage of the word "However" was removed from the sentence describing the meaning of [Ramp] when used with [External Model]. In addition, Michael proposed removing this sentence (pg. 137): "Also, in this case, the R_load subparameter is optional, regardless of its value, and will be ignored by EDA tools." Michael said he thought this rule wasn't meaningful, particularly in the context of the entire paragraph. Michael said these are the core changes that should make [Ramp], I-V, V-t, Ts4file, [External Model], consistent without requiring extra burdens on the parser or significant technical changes. Ambrish questioned the new Ts4file text stating that C_comp is required in the presence of Ts4file. He said that Ts4file language should be consistent with [External Model], so C_comp should not be required for Ts4file, or alternatively C_comp would have to also be made a requirement in the presence of [External Model]. Michael agreed to alter the Ts4file changes and remove the C_comp requirement. Michael and Ambrish noted that if C_comp is not required, it does leave open the possibility that a tool that doesn't support Ts4file may not have sufficient information from the other available keywords and subparameters. Michael said he would send out an update with the new changes. BIRD220.1 update: Yifan reviewed the presentation IBIS_validation_1022.pptx, which she had sent to the ATM list the day before the meeting. It contained the results of some new experiments made in response to the questions from the previous meeting. Yifan first noted that with the original 50 Ohm load to Vcc (fixed 3.3V) test scenario, the following equation for output pad PSIJ: PSIJ_total = PSIJ_pre-driver_power_noise + PSIJ_final_driver_power_noise was only true for the rising edge. With the new experiment, using a 50 Ohm load to a non-fixed Vcc that varied with the power rail "noise", the equation for PSIJ_total did not hold for either the rising or falling edges. Yifan then shared results from some IBIS models she had created. She noted that the test SPICE model originally provided by Arpad also included an IBIS model. She said the original IBIS model had generated some odd artifacts near the top of the rising edges. She had created a new non-power-aware IBIS model and a new power-aware (Composite Current and ISSO keywords) model. She showed simulation results from the 3 models. She showed a comparison of SPICE results with only final driver stage power noise and her power aware IBIS model, and they matched. Yifan then reviewed tables summarizing PSIJ data from new simulations she had run with different driver and test load configurations. She had created a single pre-driver example using only the pullup pre-driver stage from the SPICE model. She noted one unexplained effect in the results. She said one might expect that the PSIJ at the output pad with only pre-driver noise would be the same as the PSIJ at the pre-driver output, but this was not that case for this example (slide 10). The 8-stage inverter chain example (common pre-driver) showed the expected similarity between PSIJ at the output pad and PSIJ at the pre-driver output when only pre-driver power noise is present. (slide 11) For independent pre-driver chains with similar or different delays (slides 12 and 13), the PSIJ_total equation above held up reasonably well when the test loads were connected to GND, but it generally failed for loads connected to fixed or varying Vcc. The conclusions on slide 14 were similar to earlier conclusions. For a single pre-driver stage, the algorithm can be applied successfully. If the model maker has access to the pre-driver output, they could record the pre-driver PSIJ there directly. If not, then they could perform a PSIJ simulation with noise on both the pre-driver and final drive stages and subtract out the final driver stage PSIJ computed from a power aware IBIS model simulation, since the power aware IBIS model considers all of the effects except pre-driver PSIJ. For devices with independent pre-driver stages, an "equivalent" pre-driver PSIJ can be computed and used when loads are connected to GND, but for loads connected to Vcc the algorithm fails as the pre-driver PSIJ appears to be load dependent. Arpad asked whether Yifan could incorporate the proposed PSIJ algorithm into the power-aware IBIS model she had already created and perform some comparison runs vs. the SPICE driver model. Yifan agreed. Arpad wondered whether the fact that the algorithm appeared to work when driving loads to GND but not when driving loads to Vcc, for independent pre-drivers, might be due to referencing schemes in the experiments. He said that when connected to GND we are varying the supply of the pre-driver and output stages and trying to pull up a load connected to GND. When we perform the experiments with the load connected to Vcc, we might need to make everything Vcc relative and hold the power rail steady while moving GND up and down. This would give a scenario symmetric to the load to GND scenario, and we might find we can then measure similar effects. The group discussed the loading conditions used in the 3-column examples (e.g., slides 3 and 4). The group discussed whether column 1 (pre-driver noise only) should be performed with V_fixture fixed at Vcc nominal, but column 2 (final driver noise only) should be performed with V_fixture moving with the final drive stage rail. That is, column 1 should be measured as it was in the first experiment (slide 3) and column 2 should be measured as it was in the new experiment (slide 4). Yifan said she would think about the test measurement configurations. - Curtis: Motion to adjourn. - Fangyi: Second. - Arpad: Thank you all for joining. New ARs: Michael: Prepare a new proposed update to the language surrounding Ts4file and Ramp and related cross checking that incorporates comments from the meeting. Yifan: Perform additional investigations into the applicability of BIRD220.1 for devices with independent pre-driver stages. ------------- Next meeting: 29 October 2024 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives